1. Field of the Invention
Embodiments of the present invention relate, in general, to systems and methods for configuration file management and particularly to dynamic instantiation of configuration files.
2. Relevant Background
A software package such as an application or operating system typically comprises a number of data files that are identical on all systems and a small number of configuration files that vary from system to system. These configuration files enable the otherwise identical files to be operational on multiple platforms. It is within these configuration files that the same program knows how to interact with a particular version of an operating system. For example, when a user begins the traditional installation process of a software application, the installer either asks or determines independently the type and version of the computer's operating system. From that information particular aspects of the configuration file work to modify the otherwise identical files so that the application can function properly.
Often such configuration files are among multiple applications or packages. For example, multiple configuration files may commonly identify the host name of a computer as “/etc/hostname” configuration file. The syntax of the file typically determines what information is provided. This information, typically in ASCII text, can be created or modified by a human user via a text editor. Thus configuration files, the files controlling the operation of an application, can be modified. However, it is not uncommon for multiple configuration files, typically used by different applications or packages, to contain redundant information.
Many software applications access a relevant set of configuration files only once to retrieve information that is needed for the operation of the program. Other applications access configuration files every time the information is needed. And, yet, other applications cache configuration data and re-read it periodically or upon a specific event.
Typically, the configuration files are created during an initial system installation. However, it is not uncommon for the configuration parameters to change after the initial installation. Such a change can result in a modification of one or more configuration files. For the change to take effect, any application and operating component controlled by any of the changed parameters must restart. This can be accomplished either by a restart of the whole system (reboot), or by a restart of the relevant individual applications and operating system components if such a restart operation is supported by the operating system.
However, applications and operating system components may read the configuration files while the configuration files are being changed. This can result in an inconsistent or even incorrect view of configuration data leading to disastrous results. For example, assume that an application requires configuration files A, B, and C and that the application retrieves information from the files as needed. Assume further that a change is required to each of the configuration files. So while the file change may be complete for file A, ongoing for B, and yet to be accomplished for C, the system may access files A, B, and C for data. The result is data that is inconsistent and possibly incompatible. Until the change is complete the application is unreliable.
Compartmentalization of the configuration (customization) settings in a collection of simple ASCII files rather than, for example, a structured database, allows for a broad range of tools capable of manipulating configuration data, including a variety if editing programs, script interpreters, etc. However, a collection of regular files lacks transactional properties. This means that mutators (programs that change the settings) and accessors (programs that access the settings) of the configuration settings may have an inconsistent (invalid) view of the settings.
For example, consider that an application requires configuration files A and B. Further, consider that mutator programs X and Y are executing concurrently and making different changes to A and B. Both programs read both A and B and then write new versions of these files (AX, BX, AY, and BY respectively). It is possible that the mutator program X writes the file A first, then Y writes files A and B and then X writes file B. In such a case the resulting state will be AY and BX, and it might be inconsistent thus making the application unreliable.
When software is controlled by a single vendor it is possible to minimize this problem by combining all the configuration settings in a single transactional repository for configuration services, e.g. registry in Windows® or netinfo database in MacOS®. However, this approach is impractical in the UNIX/LINUX environment. UNIX/LINUX migration from a collection of regular ASCII configuration files to a single transactional repository would require modifications to hundreds if not thousands of applications developed by hundreds of different developers.
File system virtualization layer described in co-pending and commonly assigned U.S. patent application Ser. No. 12/035,132 entitled “Dynamic Composition of an Execution Environment from Multiple Immutable File System Images” now U.S. Pat. No. 7,805,409, the contents of which are incorporated by reference in their entirety, can combine (overlay) multiple immutable file system trees into a single virtual tree. Thus, one can identify and separate all the configuration files that differ between systems, create for each system an immutable file system image with the most current version of configuration data, and use file system virtualization to overlay the configuration tree over the file system content common for all the systems.
In this approach, the locations (pathnames) and the contents of the configuration files in the immutable file system image are identical to the regular configuration files—thus there is no difference to the configuration consumers. However, to make a change to any of the configuration files, one must modify the original copy of the file (kept somewhere else), then recreate the immutable file system image, and finally rebuild and replace the virtual tree. While the later steps of this process can be easily automated, the configuration providers would have to modify the configuration files in a copy of the file image different from the one accessed by the consumers. This change might have only trivial implications when the configuration files are generated from some other repository, but it might require substantial changes to the legacy system administration software.